During a boot operation of a computer system, a power-on self-test (POST) is performed, and an operating system is located from among the disk drives of the computer system. The Master Boot Record (MBR) is the information in the first sector of the bootable hard drive that identifies how and where an operating system is located so that it can be booted (loaded) into the computer's main memory or RAM (random access memory). The MBR is also sometimes called the “partition sector” or the “master partition table” because it includes a table that locates each partition that the hard disk has been formatted into. In addition to this table, the MBR also includes a program that reads the boot sector record of the partition containing the operating system to be booted into RAM. In turn, that record contains a program that loads the rest of the operating system into RAM. This information is critical, because without it, the computer system cannot be run and files cannot be found.
Situations exist where the MBR must be modified to run maintenance routines. Examples of this include modifying the boot loader to boot into a different operating system (OS) partition, such as DOS versus a Linux partition, or use of third party utility programs that modify the MBR for system maintenance, such as PowerQuests's VIRTUAL FLOPPY, which allows for an OS, such as DOS or Linux, to be booted from a non-DOS-based system (e.g., WIN NT's NTFS (NT file system).
A problem with programs which modify the MBR is the potential that they will prohibit a system from properly booting if some unforeseen event occurs. Examples of these events could be code bugs, incompatibilities with other applications, a system hang during the virtual floppy boot, etc. In the VIRTUAL FLOPPY application, for instance, the MBR is modified while the native protected mode OS is running. The system then shuts down and an IPL (initial program load) is forced. During this IPL, the BIOS (basis input/output system) reads the MBR into memory, validates it for correctness, and passes control to the partition entry which is labeled active. If the MBR either does not have the correct bytes in the correct location, has an invalid partition entry, has no active partition, or has a problem within the code which hooks this boot process, the system will stop with an error message (i.e., ‘no bootable partition’, ‘error loading OS’, etc.) or will just hang in a non-operating state. Furthermore, if the VIRTUAL FLOPPY maintenance routine hangs due to an errant condition, the system is stuck in this mode, because it cannot undo itself.
Manual recovery operation, generally with a bootable floppy, CD, etc., is one way of overcoming the hang situation. If a MBR gets corrupted, recovery diskettes can be used locally to restore the system back to its prior state. Remote restoration is not possible, because an Enterprise Software Distribution package requires the OS to be up and running and is managed via an agent. If there is a problem with a MBR modification process due to some undetected incompatibility, all systems (servers, clients, POS registers, etc.) could be put into a remotely unrecoverable state. This risk may prohibit administrators from performing any system maintenance routines remotely, which implement a VIRTUAL FLOPPY by modifying the MBR.
Accordingly, a need exists for an automated detection and correction mechanism in the event that a system gets into an improper or corrupted MBR state. The present invention addresses such a need.